Embedded systems are special purpose or customized devices controlled by a computer system through software application programs and hardware drivers which run on some form of operating system. Through software control these embedded systems are customized to provide a variety of features, forming a very broad market for these devices. For example, embedded systems include personal information managers, set-top boxes for cable, satellite, and Internet TV, or any smart device created using a computer system such as a smart dishwasher. An embedded system may be any device having a processor and peripheral hardware run under software control.
A typical process flow for developing an embedded system includes a software design flow and a hardware design flow where both flows develop separately according to a common specification. The testing and verification of software typically do not occur until a suitable hardware prototype, such as through an ASIC, (Application Specific Integrated Circuit), is created at the hardware creation stage. Waiting to test the software and hardware portions until a hardware prototype has been created extends the overall design cycle if re-work is required to make the software and hardware components compatible with each other.
One method known for detecting design flaws early in the process integrates the development of the software and hardware by performing software debugging and verification before an actual working hardware prototype is completed. This approach provides the opportunity for a shorter time to market and higher product quality since testing may be accomplished through either a hardware or a software solution (or both), and before any time and money is spent developing a physical implementation that may not be compatible with the software components developed.
Typically, a software debug session is performed in a single executing environment. That is, a particular debug session is typically performed entirely either on actual hardware, a hardware tool, or a simulator. Debugging can include anything required to bring any software and/or hardware up to operating mode dependability. Thus, debugging is a process of detecting, locating, and correcting a problem in a software program and/or hardware. Further, a software program which does not provide a desired result may be said to have a bug, even when debugging such a program may result in making no changes to the actual instructions, or software program, itself. Thus, debugging software can include identifying faulting instructions and simply changing context to enable further execution of instructions.
Debugging software using hardware tools like an in-circuit emulator (ICE) or scan based debugger (like RISCWatch) can be expensive. Thus, it may be cost prohibitive to provide hardware-debugging tools for all developers, or even for all testers. Further, a given hardware tool may slow down the execution of the software. For example, it may take more time to reproduce a problem on a hardware tool than if the same program ran on the real hardware. Furthermore, if multiple processors have to be debugged simultaneously, accurately reproducing a problem may be virtually impossible using some debugging tools.
Alternately, the software may be debugged using a simulator. A simulator may be, for example, either a functional or cycle accurate simulator, or some combination of the two. A simulator can provide very detailed internal state information and fine control when interacting with multiple processors. This is especially true when interacting with multiple Instruction Set Architectures, or ISAs. However, debugging software exclusively on a simulator can be problematic. For example, the debugging may be very time consuming. That is, if the problem(s) appear after running the software program on hardware for a significant time such as several minutes or hours, the same problem(s) may not be encountered on a simulator for a translated significant time of hours or days.
An emulator (especially those which are FPGA-based, such as Quickturn or Aptix) provides an environment for detailed debug of the hardware, much like the simulator environment. An emulator is significantly faster (e.g., by two or more orders of magnitude) than a simulator but may come with a steep price tag (i.e., specialized hardware may be required).
Thus, each executing environment has associated benefits and limitations. Although actual hardware may execute the fastest, it may not yield much information about the execution of the program other than whether or not the program terminates prematurely. Hardware tools are expensive, may slow down software execution, and are limited in their ability to debug multiple processors simultaneously. Software simulators may execute very, very slowly and may be limited in their ability to exactly replicate hardware functionality. Hardware emulators may be faster than simulators; however they may also be even more expensive than hardware tools. It may therefore be desirable to perform debug using more than one executing environment.
Accordingly, a need exists whereby detailed debug may be performed less expensively and faster than current methods, systems, and devices allow. Further, a need exists whereby software debug may be performed interchangeably among actual hardware, hardware tools, emulators, and simulators. The various advantages and disadvantages are summarized in TABLE 1 below:
TABLE 1DEBUGCOST PERDEBUGDEBUG DETAIL &METHODDEVELOPERSPEEDDEBUG CONTROLHARDWAREcheaperfastestleastHW TOOLSexpensivefasterlessFPGA-BASEDmost expensiveslowermoreEMULATORSIMULATORcheapestslowestmost